\documentclass[a4paper,10pt]{article}

\usepackage[utf8]{inputenc}
\usepackage{t1enc}

\usepackage[utf8]{inputenc}
\usepackage{t1enc}
\usepackage[spanish]{babel}
\usepackage[pdftex,usenames,dvipsnames]{color}
\usepackage[pdftex]{graphicx}
\usepackage{enumerate}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage[table]{xcolor}
\usepackage[small,bf]{caption}
\usepackage{float}
\usepackage{subfig}
\usepackage{listings}
\usepackage{bm}
\usepackage{times}

\begin{document}
\setcounter{secnumdepth}{5}
\setcounter{tocdepth}{5}

\renewcommand{\lstlistingname}{C\'odigo Fuente}
\lstloadlanguages{Octave} 
\lstdefinelanguage{MyOctave}[]{Octave}{
        deletekeywords={beta,det},
        morekeywords={repmat}
} 
\lstset{
        language=MyOctave,
        stringstyle=\ttfamily,
        showstringspaces = false,
        basicstyle=\footnotesize\ttfamily,
        commentstyle=\color{gray},
        keywordstyle=\bfseries,
        numbers=left,
        numberstyle=\ttfamily\footnotesize,
        stepnumber=1,                   
        framexleftmargin=0.20cm,
        numbersep=0.37cm,              
        backgroundcolor=\color{white},
        showspaces=false,
        showtabs=false,
        frame=l,
        tabsize=4,
        captionpos=b,               
        breaklines=true,             
        breakatwhitespace=false,      
        mathescape=true
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%% begin TITLE PAGE %%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{titlepage}
        \vfill
        \thispagestyle{empty}
        \begin{center}
                \includegraphics{./images/itba_logo.png}
                \vfill
                \Huge{Trabajo Pr\'actico Especial - Pre-entrega}\\
                \vspace{1cm}
                \Huge{Protocolos de Comunicaci\'on}\\
        \end{center}
        \vfill
        \large{
        \begin{tabular}{lcr}
                Crespo, Alvaro && 50758 \\
                Susnisky, Dar\'io && 50592\\
                Wassington, Axel && 50124\\
        \end{tabular}
}
        \vspace{2cm}
        \begin{center}
                \large{9 de mayo de 2012}\\
        \end{center}
\end{titlepage}
\newpage

\setcounter{page}{1}

\tableofcontents

\newpage
\section{RFCs relevantes para el desarrollo de este trabajo pr\'actico}

\begin{itemize}
    \item RFC 2616 --- Hypertext Transfer Protocol -- HTTP/1.1
    \item RFC 2068 --- Hypertext Transfer Protocol -- HTTP/1.1
    \item RFC 1945 --- Hypertext Transfer Protocol -- HTTP/1.0
    \item RFC 2119 --- Key words for use in RFCs to Indicate Requirement Levels
    \item RFC 822  --- Standard for the format of ARPA Internet text messages
    \item RFC 1590 --- Media Type Registration Procedure
    \item RFC 2046 --- Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
    \item RFC 2047 --- MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text
    \item RFC 2396 --- Uniform Resource Identifiers (URI): Generic Syntax
    \item RFC 1766 --- Tags for the Identification of Languages
    \item RFC 1738 --- Uniform Resource Locators (URL)

\end{itemize}


\newpage
\section{Protocolos desarrollados}

    \subsection{Introducci\'on}

    A continuaci\'on se presentar\'a las especificaciones para dar un breve entendimiento 
    de los protocolos para acceder al monitoreo del proxy y para acceder a la configuraci\'on del mismo.

        \subsubsection{Prop\'osito}

        Tanto el protocolo para acceder al monitoreo del proxy como el protocolo para acceder a la 
        configuraci\'on de este son protocolos que funcionan a nivel aplicaci\'on para sistemas de informaci\'on.

        El protocolo para configurar al proxy pretende enviar los datos crudos para lograr su objetivo. En cambio, 
        el protocolo para el monitoreo requiere un nivel de autenticaci\'on para luego recibir la informaci\'on 
        deseada. 

        Ninguno de los dos protocolos posee configuraci\'on extendida dando uso espec\'ifico tanto para el monitoreo 
        como para la configuraci\'on particular de un proxy.

        \subsubsection{Requerimientos}

        Las palabras DEBE, NO DEBE, REQUERIDO, HARA, NO HARA, DEBERIA, NO DEBERIA, 
        RECOMENDADO, PUEDE y OPCIONAL se deben interpretar tal y como describe el 
        RFC2119 (http://www.rfc-es.org/rfc/rfc2119-es.txt).

        \subsubsection{Terminolog\'ia}

        A configuraci\'on se incluye un listado con terminolog\'ia relevante que se usar\'a en la 
        especificaci\'on de los protocolos.

            \paragraph*{Recurso}

            Objeto o servicio de la red que puede ser identificado por una URI

            \paragraph*{Cliente}

            Un programa que establece la conexi\'on con el objetivo de enviar pedidos.

            \paragraph*{User Agent}

            El cliente que inicializa un pedido. Estos suelen ser navegadores, editores u otro 
            tipo de herramientas usadas por un usuario.

            \paragraph*{Servidor}

            Una aplicaci\'on que acepta conexiones para proveer respuestas y servicios en base 
            a pedidos. Un programa puede ser tanto como cliente como servidor, estos t\'erminos 
            hacen \'unicamente referencia al rol que el programa esta ocupando.

            \paragraph*{Servidor de origen}

            El servidor en donde un recurso en particular reside o va a ser creado.

            \paragraph*{Proxy}

            Un proxy es un programa intermediario que actua tanto como cliente como servidor 
            con el objetivo de hacer pedidos de parte de otros clientes. Los pedidos son procesados internamente 
            o pasandolos, posiblemente habiendo hecho ciertos cambios, a otros servidores. Un 
            "proxy transparente" es un proxy que no modifica ni el pedido ni la respuesta exceptuando autenticaci\'on e 
            identificaci\'on. Un "proxy no transparente" es un proxy que modifica el pedido o la respuesta con el 
            objetivo de agregarle cierto servicio al user agent.

            Para el objetivo de los protocolos implementados el concepto de proxy es esencial dado que la aplicaci\'on 
            a implementarse (y que usar\'a dichos protocolos) es un proxy.

            % Otros terminos pueden ser incluidos en esta sección!!!



    \subsection{Convenciones de notaci\'on y gram\'atica}

        \subsubsection{BNF aumentada}

        Todos los mecanismos especificados en este documento son descriptos tanto en prosa como en Backus-Naur Form (BNF) aumentada, similar a la usada por el RFC 822.
        \label{RFC 822}
        Los implementadores deber\'an estar familiarizados con esta notaci\'on para enteder esta especificaci\'on. La BNF aumentada incluye las siguientes estructuras:

        \begin{itemize}
            \item nombre = definici\'on\\
                El nombre de una regla es simplemente el nombre por s\'i mismo (sin estar contenidos por "<" y ">") y está separada de su definici\'on por el caracter igual "=".
                El espacio en blanco es solo significante en que la indentaci\'on de l\'ineas continuadas es usada para indicar una definici\'on de una regla que abarca m\'as 
                de una l\'inea. Algunas reglas b\'asicas estas en may\'usculas como SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Los s\'imbolos "<" y ">" son usados en las definiciones en los casos
                en que su presencia facilite el entendimiento del uso de los nombres de regla.
            \item "literal" \\
                Las comillas doblas rodean texto literal. A menos que expl\'icitamente se exprese lo contrario, dicho texto es \textit{case-insensitive}
            \item regla1 | regla2\\
                Los elementos separados por una barra vertical ("|") son alternativos, por ejemplo "si | no" aceptar\'a si o no.
            \item (regla1 regla2)\\
                Los elementos encerrados por par\'entesis son tratados como un solo elemento. Luego $"(elem (foo | bar) elem)"$ permite las secuencias 
                $"elem\,foo\,elem"$ and $"elem\,bar\,elem"$.
            \item *regla\\
                El caracter "*" precediendo a un elemento indica repetici\'on. La forma completa es  "<n>*<m>elemento" indicando que puede haber al menos <n> y como mucho <m>
                ocurrencias del elemento. Los valores \textit{default} son $0$ e infinito, asique "*(elemento)" permite cualquier n\'umero, incluyendo cero; "1*elemento" 
                requiere al menos uno; y "1*2element" permite uno o dos.
            \item \verb+[+ regla \verb+]+\\
                Los corchetes encierran elementos opcionales; "[foo bar]" es equivalente a "*1(foo bar)".
            \item N regla\\
                Repetici\'on espec\'ifica: "<n>(elemento)" es equivalente a "<n>*<n>(elemento)";esto es, exactamente <n> ocurrencias de (element). Luego, 2DIGIT es un n\'umero 
                de 2 cifras, y 3ALPHA es una cadena de 3 caracteres alfab\'eticos.
            \item \#regla\\
                Se utiliza para definir listas de elementos. La forma completa es "<n>\#<m>elemento" indicando por lo menos <n> y como mucho <m> elementos, cada uno
                separado por una o m\'as comas (",") y OPCIONALMENTE espacio linear en blanco, \textit{linear white space}, (LWS). Esto hace que la forma normal de usar listas 
                sea muy sencilla; una regla como\\
                \[( \text{*}LWS\,elemento\,\text{*}(\,\text{*}LWS\,","\,\text{*}LWS\,elemento ))\]
                puede representarse como\\
                \[1\#elemento\]
                Cuando esta estructura sea usada, los elementos nulos, $null$, son permitidos, pero no contribuyen a la cantidad de elementos presentes. Esto es, 
                $"(elemento), , (elemento) "$  est\'a permitido, pero solo cuenta como 2 elementos. Por lo tanto, cuando al menos uno elemento sea requerido, al menos un elemento
                no nulo DEBE estar presente. Los valores \textit{default} son $0$ e infinito, asique "\#element" permite cualquier cantidad, incluyen cero; $"1\#elemento"$ requiere
                al menos uno; y $"1\#2elemento"$ permite uno o dos.
%             \item ; comentario\\
%                 Un punto y coma, puesto a alguna distancia a la derecha de una regla de texto, empieza un comentario que continua hasta el final de l\'inea. Esta es una forma muy
%                 simple de incluir notas \'utiles en media de las especificaciones.
            \item *LWS implicado\\
                La gram\'atica descripta por esta especificaci\'on es basada en palabras. Excepto cuando se exprese lo contrario, el espacio linear en blanco (LWS) puede ser 
                incluido entre dos palabras adyacentes, y entre palabras y separadores adyacentes, sin cambiar la interpretaci\'on del campo. Al menos un delimitador 
                (LWS y/o separadores) DEBE existir entre dos \textit{tokens} cualesquiera, (para la definici\'on de "token" que sigue), dado que sino ser\'ian interpretados 
                como un solo \textit{token}.        
        \end{itemize}

        \subsubsection{Reglas b\'asicas}

        Las siguientes reglas son usadas a lo largo de esta especificaci\'on para describir estructuras b\'asicas de an\'alisis sint\'actico.
        El set de caracteres US-ASCII est\'a definido por ANSI X3.4-1986.
        
        \begin{eqnarray*} 
            OCTET          & = & <cualquier\,secuencia\,de\,datos\,de\,8\,bits> \nonumber\\
            CHAR           & = & <cualquier\,caracter\,US-ASCII\,(octetos\,0\,-\,127)> \nonumber\\
            UPALPHA        & = & <cualquier\,letra\,may\'uscula\,US-ASCII\,"A".."Z"> \nonumber\\
            LOALPHA        & = & <cualquier\,letra\,min\'uscula\,US-ASCII"a".."z">  \nonumber\\
            ALPHA          & = & UPALPHA\,|\,LOALPHA  \nonumber\\
            DIGIT          & = & <cualquier\,d\'igito\,US-ASCII\,"0".."9">  \nonumber\\
            CTL            & = & <cualquier\,caracter\,de\,control\,US-ASCII\,(octetos\,0\,-\,31)\,y\,DEL\,(127)>  \nonumber\\
            CR             & = & <retorno\,de\,carro,US-ASCII\,CR,\,(13)>  \nonumber\\
            LF             & = & <salto\,de\,l\'inea,US-ASCII\,LF,\,(10)>  \nonumber\\
            SP             & = & <espacio,US-ASCII\,SP,\,(32)>  \nonumber\\
            HT             & = & <tab\,horizontal,US-ASCII\,HT,\,(9)>  \nonumber\\
            <">            & = & <comillas\,dobles,US-ASCII,\,(34)>  \nonumber\\
        \end{eqnarray*}

        Nuestra especificaci\'on define la secuencia CR LF como el marcador de fin de l\'inea para todos los elementos del protocolo. 

        \begin{eqnarray*}
            CRLF         &  =  & CR LF \nonumber\\
        \end{eqnarray*}

        Todo espacio linear en blanco (LWS) tiene la misma sem\'antica que SP. Un recipiente PUEDE reemplazar cualquier LWS por un solo SP antes de interpretar el valor del 
        campo o pasar el mensaje

        \begin{eqnarray*}
                LWS          & = & [CRLF] 1\text{*}( SP | HT ) \nonumber\\
        \end{eqnarray*}

        La regla TEXT se usa solamente para contenidos descriptivos de un campo y valores que no se supone que sean interpretados por el \textit{parser} del mensaje.
        Palabras de  *TEXT PUEDEN contener caracteres de otros sets de caracteres aparte del ISO- 8859-1, solo cuando sean encodeados de acuerdo a las reglas del 
        RFC 2047 \label{RFC 2047}

        \begin{eqnarray*}
                TEXT         & = & <cualquier\,OCTET\,excepto\,CTLs,\nonumber\\
                            &   & pero\,incluyendo\,LWS>\nonumber\\
        \end{eqnarray*}

        Los caracteres num\'ericos hexadecimal son usados en varios elementos del protocolo.

        \begin{eqnarray*}
                HEX           & = &   ``A"\,|\,``B"\,|\,``C"\,|\,``D"\,|\,``E"\,|\,``F"\nonumber\\
                            &   & \,|\,``a"\,|\,``b"\,|\,``c"\,|\,``d"\,|\,``e"\,|\,``f"\,|\,DIGIT\nonumber\\
        \end{eqnarray*}


        Muchos valores de campos consisten en palabras separadas por un LWS o caracteres especiales. Estos caracteres especiales DEBEN estar entre commillas dobles 
        para ser usados dentro de un valor de un par\'ametro.

        \begin{eqnarray*}
            token         & = & 1\text{*}<cualquier\,CHAR\,excepto\,CTLs\,o\,separadores>\nonumber\\
            separadores    & = & ``("\,\,|\,\,``)"\,\,|\,\,``<"\,\,|\,\,``>"\,\,|\,\,``@"\nonumber\\
                &   &\,\,|\,\,``,"\,\,|\,\,``;"\,\,|\,\,``:"\,\,|\,\,``\backslash"\,\,|\,\,<"\,''\,``>\nonumber\\
                &   &\,\,|\,\,``/"\,\,|\,\,``["\,\,|\,\,``]"\,\,|\,\,``?"\,\,|\,\,``="\nonumber\\
                &   &\,\,|\,\,``\verb+{+"\,\,|\,\,``\verb+}+"\,\,|\,\,SP\,\,|\,\,HT\nonumber\\
        \end{eqnarray*}


%         Se puede incluir comentarios en algunos campos rodeando el texto de comentario con par\'entesis. Los comentarios son permitidos solamente en aquellos campos 
%         que contengan "comentario" como parte de su definici\'on de valor de campo. En todos los otros casos, los par\'entesis son considerados como parte del valor del campo.
%         \begin{eqnarray*}
%             comentario       & = & "("\,\,\text{*}(\,ctext\,\,|\,\,|\,\,comentario,)\,\,")"\nonumber\\
%             ctext         & = & <cualquier\,\,TEXT\,\,excluyendo\,\,``("\,\,y\,\,``)">\nonumber\\
%         \end{eqnarray*}
% 
% 
% 
%         Una cadena de texto es analizada como una sola palabra se esta rodeada de comillas dobles.
% 
%         \begin{eqnarray*}
%             quoted-string & = & (\,\,<">\,\,\text{*}(qdtext\,\,|\,\,)\,\,<">\,\,)\nonumber\\
%             qdtext        & = & <cualquier\,\,TEXT\,\,excepto\,\,<">>\nonumber\\
%         \end{eqnarray*}

\newpage

    \subsection{Protocolo para acceder al monitoreo del proxy}

        \paragraph*{Funcionamiento general}

        Este protocolo es un protocolo de pedido y respuesta con el objetivo de obtener informaci\'on 
        de monitoreo del proxy. Para poder realizar la comunicaci\'on correctamente se env\'ian datos 
        de autenticaci\'on en el pedido del cliente. Para que el servidor realmente devuelva la 
        informaci\'on correcta, es importante que la autenticaci\'on sea correcta. El formato y la 
        informaci\'on enviada tanto en el pedido como en la respuesta ser\'an aclarados en secciones 
        posteriores.

        Es necesario precisar que toda conexi\'on dada por este protocolo es iniciada por una aplicaci\'on cliente (por ejemplo netcat)
         y en este caso un proxy funciona de servidor para proveer a un usuario datos 
        posiblemente relevantes del mismo.

        Para poder utilizar este protocolo se reservar\'a un puerto especifico que debe ser conocido 
        por el cliente para poder establecer la conexi\'on. No es exclusivo, pero se asume que este 
        protocolo es montado sobre TCP/IP, corroborando as\'i integridad y seguridad en la transferencia 
        de los datos.

        Por \'ultimo es util resaltar que en cada pedido de este protocolo se esta generando una nueva 
        conexi\'on.
        %ALVAMASTER CUCHAME, NO HAY QUE PONERLE NINGUN TIPO DE HEADER ACLARANDO QUE PROTOCOLO ES?!?!?!

        \subsubsection{Mensaje del Protocolo}
            Los mensajes del protocolo consisten de solicitudes por parte del cliente y respuestas por parte del servidor proxy.

            \begin{eqnarray*}
                mensaje  & = &\,\,Solicitud\,\,|\,\,Respuesta\nonumber\\
            \end{eqnarray*}

        \subsubsection{Solictud}
        Una solicitud del cliente al servidor proxy incluye el username y el password del usuario que actual.

        \begin{eqnarray*}
                Solicitud\ & = & \verb+"monitor"+\,\,SP\,\,User\,\,SP\,\,Password\,\,CRLF\nonumber\\
        \end{eqnarray*}


        \paragraph*{User y Password}
        User, el nombre del usuario, y password, su contraseña DEBEN ser provistos para iniciar la comunicaci\'on
        con este protocolo. El servidor autenticara estos datos para permiter o rechazar el monitoreo.
            
    \subsubsection{Respuesta}
    
    Los mensajes de respuesta tienen como contenido en primer lugar el c\'odigo de respuesta y en caso de ser un 
    pedido aceptado tambi\'en contendra la informaci\'on correspondiente al monitoreo.

    \begin{eqnarray*}
            Respuesta\ & = &\,\,Codigo\,\,SP\,\,\verb+[Datos de monitoreo]+\nonumber\\
    \end{eqnarray*}
    
    \paragraph*{C\'odigo de respuesta}
        El c\'odigo de respuesta indica si la operaci\'on fue realizada con \'exito o no.

        \begin{eqnarray*}
            Codigo\ & = & \verb+"200 OK"+\,\,|\,\,\verb+"401 UNAUTHORIZED"+\nonumber\\
        \end{eqnarray*}

    \paragraph*{Datos de monitoreo}

    El protocolo tiene el potencial de proveer al usuario de ciertos datos del monitoreo del proxy que se 
    especifican a continuaci\'on

    \paragraph*{Bytes-transferred:} Cantidad total de bytes transferidos.
    \paragraph*{Bytes-transferred-clients:} Bytes transferidos entre clientes y el proxy.
    \paragraph*{Bytes-transferred-servers:} Bytes transferidos entre el proxy y los origin servers.
    \paragraph*{Total-filters-applied:} Cantidad de filtros que fueron aplicados.
    \paragraph*{All-access:} Cantidad de pedidos.
    \paragraph*{Ip-filter:} Cantidad de pedidos filtrados por la direcci\'on IP.
    \paragraph*{URL-filter:} Cantidad de pedidos filtrados por la URL.
    \paragraph*{Media-type-filter:} Cantidad de pedidos filtrados por el tipo de recurso.
    \paragraph*{Size-filter:} Cantidad de pedidos filtrados por tamaño.
    \paragraph*{L33t-transformations:} Cantidad de conversiones a lenguaje L33t.
    \paragraph*{Images-transformations:} Cantidad de imagenes transformadas.
    \paragraph*{Connections-open:} Cantidad de conexiones abiertas (clientes y origin server)

\newpage
    \subsection{Protocolo para acceder a la configuraci\'on del proxy}

        \paragraph*{Funcionamiento general}

        Este protocolo es un protocolo de pedido y respuesta con el objetivo modificar la 
        configuraci\'on actual del proxy en tiempo de ejecuci\'on. Si bien es un protocolo de pedido y respuesta, la 
        respuesta no provee informaci\'on particularmente relevante sino que simplemente es 
        una confirmaci\'on del resultado de la operaci\'on. 

        El formato y la informaci\'on enviada tanto en el pedido como en la respuesta ser\'an 
        aclarados en secciones posteriores.

        Es necesario precisar que toda conexi\'on dada por este protocolo es iniciada por una aplicaci\'on cliente (por ejemplo netcat)
        y en este caso un proxy funciona de servidor, modificando su configuraci\'on y retornando 
        un c\'odigo de respuesta.

        Para poder utilizar este protocolo se reserva un puerto especifico, el puerto $2021$, que debe ser conocido 
        por el cliente para poder establecer la conexi\'on. No es exclusivo, pero se asume que este 
        protocolo es montado sobre TCP/IP, corroborando as\'i integridad y seguridad en la transferencia 
        de los datos.

        Por \'ultimo es \'util resaltar que en cada pedido de este protocolo se esta generando una nueva 
        conexi\'on.
        %ALVAMASTER CUCHAME, NO HAY QUE PONERLE NINGUN TIPO DE HEADER ACLARANDO QUE PROTOCOLO ES?!?!?!

        \subsubsection{Parametros del protocolo}

            \paragraph*{Media Type}
            El protocolo usa \textit{Media Types} en el filtro para bloquear determinados tipos de datos, dado que es el mismo mecanismo para definir tipos de datos
            que utiliza el protocolo HTTP.

            \begin{eqnarray*}
                    media-type    & = & type "/" subtype \nonumber\\ %*( ";" parameter ) ???
                    type          & = & token\nonumber\\
                    subtype       & = & token\nonumber\\
            \end{eqnarray*}

            Los valores para $type$ y $subtype$ son \textit{case- insensitive}. 
            NO SE DEBE usar espacio linear en blanco (LWS) entre el tipo y el subtipo.

            \paragraph*{Expresiones Regulares}
            Algunos filtros reciben como par\'rametro expresiones regulares (por ejemplo para determinar las URIs bloqueadas). Estas expresiones regulares est\'an 
            basadas en el Basic Regular Expression (BRE) standard de IEE POSIX.
            Utilizaremos las expresiones regulares
            

            \paragraph*{Direcci\'on IP}
            Para ciertos filtros se utilizan direcciones IPs como par\'ametros. Las direcciones IPs utilizadas en esta especificaci\'on tienen la siguiente forma:

            \begin{eqnarray*}
                    ip-adress    & = &  number\,\,\verb+"."+\,\,number\,\,\verb+"."+\,\,number\,\,\verb+"."+\,\,number\nonumber\\
                    number       & = &  <valor decimal de un OCTET (0 - 255)>\nonumber\\
            \end{eqnarray*}
                
        \subsubsection{Mensaje del protocolo}

            \paragraph*{Tipos de mensaje}
            Los mensajes del protocolo consisten de solicitudes por parte del cliente y respuestas por parte del servidor proxy.

            \begin{eqnarray*}
                mensaje  & = &\,\,Solicitud\,\,|\,\,Respuesta\nonumber\\
            \end{eqnarray*}


        \subsubsection{Solictud}
        Una solicitud del cliente al servidor proxy incluye el identificador del filtro o transformador, la operaci\'on deseada y uno o m\'as par\'ametros opcionales.

%         config-filter n (operaci\'on) [parametros]
        \begin{eqnarray*}
                Solicitud\ & = & \verb+"config-filter"+\,\,SP\,\,id-filtro\,\,SP\,\,operacion\,\,SP\,\,\verb+[+parametros\verb+]+\,\,CRLF\nonumber\\
        \end{eqnarray*}

            \paragraph*{Identificadores de filtros}
            Los identificadores de los filtros son simplemente n\'umeros decimales. Hasta el momento hay 7 filtros, en caso de agregarse uno nuevo se deber\'a 
            asignar el n\'umero correspondiente como su identificador.

            \begin{eqnarray*}
                id-filtro & = & 1\,\,|\,\,2\,\,|\,\,3\,\,|\,\,4\,\,|\,\,5\,\,|\,\,6\,\,|\,\,7\nonumber\\
            \end{eqnarray*}
            
            \paragraph*{Operaci\'on}
            La operaci\'on a realizar indica la habilitaci\'on, o no, del filtro. Por lo que solo hay dos operaciones posibles, habilitar o deshabilitar.

            \begin{eqnarray*}
                operacion & = & (\verb+"enable"+\,\,|\,\,\verb+"disable"+)\nonumber\\
            \end{eqnarray*}
            
            \paragraph*{Par\'metros}
            Algunos m\'etodos requieren de uno o m\'as par\'ametro. Dada que estos varian de manera significante de acuerdo al m\'etodo, se los discutir\'a 
            posteriormente.
        
        \subsubsection{Respuesta}

        Despu\'es de recibir e interpretar un mensaje de solicitud, el servidor proxy responde con un mensaje de respuesta.
        
        \begin{eqnarray*}
           Respuesta    & = & Linea\,\,de\,\,estado \nonumber\\
        \end{eqnarray*}

            \paragraph*{L\'inea de estado}
            Dado que las respuestas de este protocolo no requieren transferir informaci\'on, la respuesta consiste solamente de una l\'inea en la que se 
            expresa el resultado y el estado de la solicitud pedida. Esta consiste de un c\'odifo de estado seguido de una frase textual que lo describe brevemente, 
            ambos separados por caracteres SP. No se admiten CR o LF excepto en la secuencia CRLF final.
            
            \begin{eqnarray*}
                Linea\,\,de\,\,estado    & = & Codigo\,\,de\,\,estado\,\,SP\,\,Frase-razon\,\,CRLF \nonumber\\
            \end{eqnarray*}

            \paragraph*{C\'odigo de estado y Frase-raz\'on}
            El c\'odigo de estado es un entero de 3 d\'igitos que representa el intento de entender y satisfacer la solicitud.
            La Frase-raz\'on tiene la finalidad de dar una descripci\'on corta y textual del C\'odigo de estado. El 
            
            \begin{eqnarray*}
                Codigo\,\,de\,\,estado   & = &  200\,\,|\,\,400\,\,|\,\,500\,\,| codigo-extension \nonumber\\
                codigo-extension        & = &   3DIGIT\nonumber\\
                Frase-razon             & = &   \verb+*+<TEXT,\,\,excluyendo\,\,CR,\,\,LF>
            \end{eqnarray*}
            
            El c\'odigo $200$ va acompañado de la frase $OK$ y significa que la solicitud pudo satisfacerse correctamente.\\
            El c\'odigo $400$ va acompañado de la frase $BAD\,\,REQUEST$ y significa que hubo un error en la solicitud, probablemente de sintaxis.\\
            El c\'odigo $500$ va acompañado de la frase $INTERNAL\,\,ERROR$ y significa que hubo un error interno del servidor proxy. 
            Se aconseja contactar a un administrador o reintentar m\'as tarde.\\

        \subsubsection{M\'etodos}
        
            \paragraph*{Filtro Nº1}
%             Bloquear todo acceso. 
%             config-filter 1 (enable | disable)
            La activaci\'on de este filtro implica el bloqueo de tipo de acceso al servidor proxy. Esto es, toda solicitud que se se le haga 
            al proxy DEBE fallar.
            Este m\'etodo no requiere par\'ametros.

            \paragraph*{Filtro Nº2}
%              bloquear acceso a cierto IP destino o grupo de ellos
%              config-filter 2 (enable | disable) [ip-adress or mask]
             La activaci\'on de este filtro implica el bloqueo de determinada IP o grupos de IPs. Luego, toda solicitud dirigida a esa/s IP/s DEBE
             fallar. Este m\'etodo recibe como par\'ametro la direcci\'on de IP o una mascara para describir grupos de IPs.

            \begin{eqnarray*}
                parametro & = & ip-adress\,\,|\,\,exp-reg\nonumber\\
            \end{eqnarray*}

            \paragraph*{Filtro Nº3}
%             bloquear por expresiones regulares de URI destino: Piense en un bloqueador de publicidad donde por ejemplo se quiere bloquear
%             todos los requests hacia http:// adserver.example.org/ads/*.
%             config-filter 3 (enable | disable) url-regexp
            La activaci\'on de este filtro implica el bloqueo de las URIs destino que matchean una determinada expresi\'on regular. Entonces, toda solicitud dirigida
            a un host cuya URI est\'e dentro del gruo de URIs filtradas, DEBE fallar. Este m\'etodo recibe como par\'ametro la expresi\'on regular
            en cuesti\'on.

            \begin{eqnarray*}
                parametro & = & exp-reg\nonumber\\
            \end{eqnarray*}

            \paragraph*{Filtro Nº4}
%             bloquear acceso a ciertos Media Types: Con esta funcionalidad se podria bloquear accesos a descargas de archivos (aun cuando estos no tengan una URI
%             reconocible (ej: .exe).  Por ejemplo si se accede (logueado en IOL) a http://iol.itba.edu.ar/itbaV/startDownload.asp? fiid=82630 y se 
%             tiene prohibido el media type application/octet-stream la descarga deberia fallar.
%             config-filter 4 (enable | disable) media-type
            La activaci\'on de este filtro implica el bloqueo de las solicitudes que intenten descargar determinados \textit{Media Types}. Entonces, las solicitudes
            que intenten descargar alg\'un \textit{Media Type} sobre el cual exista un bloqueo DEBEN fallar. Este m\'etodo recibe como par\'ametro el 
            \textit{Media Type} a bloquear.
            
            \begin{eqnarray*}
                parametro & = & media-type\nonumber\\
            \end{eqnarray*}


            \paragraph*{Filtro Nº5}
%             bloquear accesos a recursos muy grandes: No permitir descargas mayores a cierta cantidad de bytes.  (Tener en cuenta el header Content-Lenght, y en su 
%             ausencia simplemente los bytes transferidos)
%             config-filter 5 (enable | disable) size-in-bytes
            La activaci\'on de este filtro implica el bloqueo de solicitudes que intenten descargar recursos de mayor tamaño al especificado. Luego, las solicitudes
            que intenten descargar alg\'un recurso de mayor tamaño que el que el filtro determina, DEBEN fallar. Este m\'etodo recibe como par\'ametro el tamaño
            m\'aximo aceptado, en bytes.

            \begin{eqnarray*}
                parametro & = & size-in-bytes\nonumber\\
            \end{eqnarray*}

            \paragraph*{Filtro Nº6}
%             transformar texto a formato l33t: Tendra que ser posible modificar el contenido de un recurso que dice ser text/plain realizando las siguientes sustituciones:
%                 *  a por 4 (cuatro)
%                 *  e por 3 (tres)
%                 *  i por 1 (uno)
%                 *  o por 0 (cero)
%             config-filter 6 (enable | disable)
            La activaci\'on de este filtro no implica ninguna clase de bloqueo sino la aplicaci\'on de una transformaci\'on de texto a formato \textit{33t}. 
            Dicha transformaci\'on se aplica solo a los contenidos de los recursos que cuyo \textit{Media Type} sea \textit{text/plain}. 
            Los cambios a aplicar son los siguientes:
            \begin{itemize}
                \item Se reemplaza la letra $a$ por un $4$ (cuatro).
                \item Se reemplaza la letra $e$ por un $3$ (tres).
                \item Se reemplaza la letra $i$ por un $1$ (uno).
                \item Se reemplaza la letra $o$ por un $0$ (cero).
            \end{itemize}
            Este m\'etodo no recibe par\'ametros.

            \paragraph*{Filtro Nº7}
%             rotar 180 grados las imagenes: Se desea rotar imagenes 180 grados para sorprender a los usuarios que estan usando el proxy.
%             config-filter 7 (enable | disable)
            La activaci\'on de este filtro tampoco implica ninguna clase de bloqueo sino la aplicaci\'on de una transformaci\'on. 
            Dicha transformaci\'on concierne solamente a las im\'agenes y consiste en rotarlas 180 grados.
            Este m\'etodo no recibe par\'ametros.



\newpage
\section{Problemas y dificultades encontrados}

    \subsection{Integraci\'on de NIO y multithreads}
        En un principio el enfoque que tomaremos hacia la construcci\'on del proxy ser\'a la de utilizar un \'unico thread que maneje un selector. 
        A su vez, este selector ser\'a el encargado de manejar todos los sockets existentes.
        Existe la posibilidad de mejorar ampliamente la performance del proxy utilizando multiples threads y multiples selectores, haciendo as\'i m\'as eficiente
         la asignaci\'on y el manejo de los distintos sockets.
        Si bien las ganancias de aplicar esto se ven inmediatamente y ya fue fueron mencionadas (incremento de la performance) esta idea no es tan sencilla de 
        implementar ya que se agrega la complejidad de sincronizar toda la aplicaci\'on, haciendo uso de elementos como \textit{locks} y sem\'aforos y teniendo 
        en cuenta condiciones de carrera.
    
    \subsection{Estado interno de una conexi\'on}
    Al crear nuestro proxy inmediatamente surge la necesidad de mantener un estado interno de la conexi\'on, a simple vista se puede ver 
    la interrelaci\'on entre los \textit{sockets} que se utilizan para comunicarse con los cliente y los  que se utilizan para comunicarse 
    con los servidores. Este requerimiento de la aplicaci\'on no es un problema trivial y es deseado resolver de una manera eficiente. 
    Una de las ideas que fueron surgiendo durante la redacci\'on de esta pre-entrega fue la de utilizar un \textit{Map} manteniendo as\'i 
    relaciones y estados entre \textit{sockets}.

    \subsection{Transfer-Encoding}
    Es posible que llegue al proxy una respuesta que incluya el header \textit{Transfer-Encoding: chunked}. 
    Esto implica que el mensaje transmitido no tiene una longitud fija. Es necesario que nuestro proxy pueda reconstruir de manera correcta este
    mensaje para luego seguir proces\'andolo. Un enfoque para esta problem\'atica es la de utilizar un filtro particular para este tipo de mensajes.

    \subsection{Cache Headers}
    Es necesario para nuestro proxy tener en cuenta los \textit{Cache headers} y los pedidos condicionales. 
    Esto se debe a que la configuraci\'on del proxy puede ser modificada entre dos pedidos. Esta posibilidad debe ser reconocida y correctamente procesada.

    \subsection{Multipart MIMEs}
    Existe la posibilidad de que la respuesta de un pedido sea de tipo \textit{multipart/*}. Nuestro proxy debe poder reconocer esta posibilidad y procesarla correctamente, tomando y procesando por separada cada parte del mensaje. Por \'ultimo el mensaje debe poder ser reconstruido para replicar la respuesta que le llega al proxy.

\newpage
\section{Aplicaciones y herramientas para desarrollo y testing}

A continuaci\'on se presentan algunas aplicaciones y herramientas varias que ser\'an \'utiles a lo largo del trabajo.

\begin{itemize}
 \item \textbf{Netcat}, para usarlo como aplicaci\'on cliente y hacer determinadas solicitudes, tambi\'en como posible servidor.
 \item \textbf{Curl}, para hacer algo similar.
 \item \textbf{User Agents} (Mozilla Firefox, Google Chrome), para probar nuestro proxy con clientes ''de la vida real``.
 \item \textbf{JMeter}, para hacer pruebas de performance y \textit{benchmarking}.
 \item \textbf{Wireshark}, para ver el contenido de paquetes y detectar errores o confirmar ideas.
 \item \textbf{Nginx}, para usar como servidor HTTP.
\end{itemize}

\newpage
\section{Casos de prueba}

    \subsection{Solicitudes inv\'alidas}
    Usando la herramienta \textit{netcat} podemos comprobar que el proxy se comporta de maner esperada cuando recibe solicitudes con m\'etodos
    que no soporta, devolviendo el status code apropiado. (m\'etodo \textit{TRACE})

    \subsection{Performance}
    A trav\'es de la herramienta \textit{JMeter} podremos efectuar pruebas de performance. Con valores como la cantidad de solicitudes satisfechas por segundo
    en distintas situaciones, podemos obtener una idea de la performance de nuestro proxy.
    
        \subsubsection{Cliente, proxy y servidor origen en un mismo host}
        Al tener todos los integrantes de la comunicaci\'on en un mismo host (utilizando herramientas como \textit{netcat} y \textit{nginx}) podremos obtener 
        los l\'imites \'ultimos de nuestro proxy. Dado que la comunicaci\'on se acortar\'a y la tasa de transmisi\'on se mucho m\'as alta, nuestro proxy ser\'a
        exigido a su m\'axima capacidad.
        
        \subsubsection{Cliente, proxy y servidor en host distintos}
        Esta medida ser\'a en verdad mucho m\'as realista y nos permitir\'a ver como se comporta el proxy en una situaci\'on de uso ordinario.
     

    \subsection{Integraci\'on con User Agents}
    Para verificar que nuestro proxy puede usar ''en la vida real``, configuraremos nuestros browser para que lo utilicen para tener una buena apreciaci\'on de como
    se comporta en una situaci\'on de trabajo.

    \subsection{Casos extraños}
    Utilizando \textit{netcat}, probaremos casos de escasa ocurrencia pero que sin embargo el protocolo HTTP considera v\'alidos. Por ejemplo, 
    campos de m\'as de una l\'inea, headers repetidos, headers faltantes, etc...


\end{document}
